API access management includes application templates that are preview features. Contact Thales Customer Support to request access to preview features.

This preview includes features with sample code to demonstrate API access management.

API access management ensures that only authenticated and authorized clients can successfully complete a call to an API. One goal of API access management is to separate mapping roles to users or groups from enforcing policies, which allows the separation of responsibilities for management tasks.

API gateways also abstract the policy enforcement from the actual API implementation. This abstraction allows an API developer to achieve the required API function, while a dedicated and specialized group implements access policies.

OAuth 2.0 and OpenID Connect

SafeNet Trusted Access (STA) uses the OAuth 2.0 and OpenID Connect (OIDC) standard mechanisms to enable you to perform API access management. Instead of client credentials, more secure and time limited access tokens are passed to the API endpoints. In addition, the JSON Web Tokens (JWT) can carry payloads for user context.

Tokens and scope

The two biggest security benefits of OAuth are using tokens instead of passing credentials and restricting the scope of tokens.

• Using credentials to obtain an access token allows you to limit the security exposure. If someone gains access to the token, they might be able to use it for a short time, but they haven't compromised the user's identity.

• Controlling what a token is entitled to access further limits damage in case of compromise. For example, scoping a token to employees limits the functionality and does not expose manager rights in case that the access tokens gets compromised.

Custom claims

The JWT specification of OAuth allows you to include custom claims in access tokens. This can be used for scoping purposes or to provide additional information to the API.

Sample scenario and components

In the sample scenario that is used in this demonstration, your customer has developed a native mobile app that accesses one or more APIs. The app and the user must be authenticated to the API, and authorized to access three specific sub-functions of the service behind the API. This means that scopes or claims must be transmitted to the API.

This scenarios implements a mobile shopping application with which a customer can locate shops on a map and see their inventory. Employees and managers can also locate warehouses, and managers can move inventory from a warehouse to a shop.

The sample scenario uses the following components to separate authentication, authorization, and API functionality:

• A client application that is unaware of users' roles but knows how to authenticate and forward an access token to the API endpoint.

• STA to ensure that the application or user gets authenticated, and that the authenticated user is mapped to a role.

• An optional API gateway that enforces API access rules based on the contents of the access token received from the client application. Alternatively, the back-end API can enforce the access rules.

• The back-end API that executes API functions but is otherwise unaware of any authentication or authorization requirements.The API can also enforce the access rules instead of an API gateway.

API access constraints

The solution implements the following API access constraints:

• Users of the application get access to view shops and their stock information, using a machine-to-machine OIDC client credential flow.

• Employees or managers are allowed to view warehouses and their stock information, using the interactive OIDC authorization code flow and Proof Key for Code Exchange (PKCE), combined with claim inspection.

• Only managers are allowed to move stock from a warehouse to a store (same as above with a specific claim inspection condition).

To display negative use cases and to show that an API access policy caught an unauthorized API request, the demo application is not aware of any restrictions and allows a user to execute all operations. If the user does not have proper authorization, an error message is displayed.

Authentication and authorization flow

The authentication and authorization information is assembled into one construct of information that the policy enforcement point can work with:

1. The application wants to access the API resource and knows that it needs to provide an access token.

2. To acquire the access token, the client application requests an access token using either the client credential flow (machine-to-machine) or the user interactive flow (authorization code with PKCE).

   For example, the following screen shot shows how Postman is configured to acquire an access token for the client credential flow (machine-to-machine):

   

   The following screen shot shows how Postman is configured to acquire an access token for the user interactive flow (authorization code with PKCE):

   

3. The access token is a signed JWT.

4. The JWT is transmitted to the API in the authorization header as a bearer token. If an API gateway is used, then this is the published endpoint on the API gateway. If no API gateway is used, then it is the API endpoint itself.

5. The policy enforcement takes place based on the JWT validation that is received in the authorization header.

   listLevel1
   Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI0Tl94ZUUwSHM0RkJ2UXdINVZNNm0zR0xDVX
   listLevel1
   {    
   listLevel1
   "exp": 1617728668,     
   listLevel1
   "iat": 1617728368,
   listLevel1
   "auth_time": 1617728365,       
   listLevel1
   "jti": "fc91d5b8-ee71-4edf-9a10-fba4bfca3148",    
   listLevel1
   "iss": "https://spedemo-sasidp.stademo.com/auth/realms/ABC123EFGH-STA",     
   listLevel1
   "aud": "a478cca2-0dbf-4093-850e-2978f8211407",      
   listLevel1
   "sub": "ba2cfb27-3938-3648-8349-83367e25d13a",      
   listLevel1
   "typ": "Bearer",
   listLevel1
   "azp": "a478cca2-0dbf-4093-850e-2978f8211407",
   listLevel1
   "session_state": "4f239a58-2f9b-493d-a3ac-de5fcdc6ee18",
   listLevel1
   "acr": "1",
   listLevel1
   "scope": "openid",     
   listLevel1
   "name": "demo user",  
   listLevel1
   "preferred_username": "demouser",
   listLevel1
   "given_name": "demo",     
   listLevel1
   "family_name": "user",
   listLevel1
   "email": "demouser@company.com",    
   listLevel1
   "group": "apigee-group"       
   listLevel1
   }